
CERTIFICATE OF MAILING 

I hereby*^ff^1ftat the below listed items are being deposited with the U.S. Postal 
Service as first class mail in an envelope addressed to: 

Assistant Commissioner- for Patents 
Box: 

Washington, D.C. 20231 



on 



H. Le Giap 
In re application of: BILLER, et aL 
U.S. Serial Number: 09/825,151 
Filing Date: April 2, 2001 



RECEIVED 

SEP Z 1 2001 
Technology Center 2100 



Art Unit: . ._2131_- 

Examiner TBA 

Our Reference Number 51207-1040 



Title: System and Method for Logins 



The following is a list of documents enclosed: 
Return Postcard; 

A certified copy of the European Application No. 00106948.3; and 
Preliminary Amendment (4 pages). 



THIS PAGE BLANK (uspto) 




%f Europaisches 
Patentamt 



European 
Patent Office 



Office europeen 
des brevets 



Beschei n i g u ng Certif i cate 



Attestation 



Die angehefteten Unterla- 
gen stimmen mit der 
ursprunglich eingereichten 
Fassung der auf dem nach- 
sten Blatt bezeichneten 
europaischen Patentanmel- 
dung Qberein. 



The attached documents Les documents fixes a 
are exact copies of the cette attestation sont 
European patent application conformes a la version 
described on the following initialement deposee de 
page, as originally filed. la demande de brevet 

europeen specif iee a la 
page suivante. 



Patentanmeldung Nr. Patent application No. Demande de brevet n° 

00106948.3 



CERTIFIED COPY OF 
PRIORITY DOCUMENT 



Der Prasident des Europaischen Patentamts: 
Im Auftrag 

For the President of the European Patent Office 

Le President de I'Office europeen des brevets 
p.o. 




I.L.C. HATTEN-HECKMAN 



DEN HAAG,DEN 
THE HAGUE, 
LA HA YE , LE 



29/08/01 



EPA/EPO/OEB Form 1014 - 02.91 






Europaisches 
Patentamt 



European 
Patent Office 



Office europeen 
des brevets 



Blatt 2 der Bescheinigung 
Sheet 2 of the certificate 
Page 2 de I'attestation 



Anmeldung Nr.: 
Application no.: 
Demande n*: 



00106948.3 



Anmeldetag: 



Date de depot: 



Date of filing: 31/03/00 



Anmelder 

Applicant(s): 

Demandeur(s): 

LHS Group Inc. ~ 

Atlanta, GA 30328 

UNITED STATES OF AMERICA 



Bezeichnung der Erfindung: 
Title of the invention: 
Titre de I'invention: 

Abrechnungs- und Kundenverwal tungs system 



In Anspruch genommene Prioriat(en) / Priority(ies) claimed / Priorite(s) revendiquee(s) 

Staat: Tag: Aktenzetchen: 

State: Date: File no. 

Pays: Date: Numero de depot: 



I nternat iona le Patentkla ssif i kat ion: 
International Patent classification: 
Classification Internationale des brevets: 



Am Anmeldetag benannte Vertragstaaten: 

Contracting states designated at date of filing: AT/BE/CH/CY/DE/DK/ES/H/FR/GB/GR/IE/IT/L(/LU/MC/NLyPT/SE/TR 
Etats contractants designes lors du depot: 



G06F 17/60 



Bemerkungen: 

Remarks: 

Remarques: 



EPA/EPO/OEB Form 1012 -11.00 




24 

3 t Mm 2000 

Abrechnungs- und Kundenverwaltungssystem 



Beschreibung 

Die vorliegende Erfindung betrifft ein Abrechnungs- und Kundenverwaltungssy- 
stem, insbesondere fur Kommunikationsdienste, nach dem Oberbegriff des An- 
spruchs 1 . 

Abrechnungs- und Kundenverwaltungssysteme werden in alien Firmen eingesetzt, 
die Guter oder Dienstleistungen anbieten, bei denen die Hohe des Verbrauchs der 
Guter bzw. die Lange der Nutzung der Dienstleistungen die wesentlichen Kriterien 
fur die Hohe des zu entrichtenden Preises durch den Endkonsumenten darstellen. 
Diese Firmen besitzen zudem meist eine sehr groSe Anzahl an Kunden (vgl. 
Strom-, Gas- und Wasserversorgung, Telekommunikation), was einen enormen 
Verwaltungsaufwand nach sich zieht. Abrechnungs- und Kundenverwaltungssy- 
steme ermoglichen solchen Firmen zumeist eine einfache Verwaltung der enormen 
Menge an Kundendaten, berechnen nach entsprechenden Voreinstellungen die 
abzurechnenden Kosten und sind meist auch fiir die Rechnungserstellung als sol- 
che zustandig. 

Bei den bekannten Abrechnungs- und Kundenverwaltungssystemen wird eine zen- 
trale Datenbank eingesetzt, die insbesondere zur Speicherung aller Anwendungs- 
daten dient. Diese ist jedoch meist als relationale Datenbank ausgebildet und stellt 
so zugleich den Hauptserver des Systems dar. Ober Clients, und insbesondere 
fiber GUIs (Graphic User Interfaces), werden dem Anwender bestimmte Dienstlei- 
stungen des Kundenverwaltungs- und Abrechnungswesens ermoglicht. Dabei kon- 
nen zusatzliche Anwendungsserver zwischen die Clients und die Datenbank ge- 
schaltet sein. Jeder Client bzw. jeder Anwendungsserver ist mit der zentralen Da- 
tenbank verbunden, von der alle zur Anwendung notigen Daten abgefragt und ge- 
andert werden konnen. 
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Zum besseren Verstandnis wird im folgenden zunachst ein typisches Ausfuhrungs- 
beispiel eines vorbekannten Abrechnungs- und Kundenverwaltungssystems im Be- 
reich der Mobilfunk-Telekommunikation unter Bezugnahme auf Fig. 1 erlautert. An 
diesem Beispiel sollen die Ablaufe innerhalb eines derartigen Systems und die 
MSglichkeiten, die das System liefern sollte, vereinfacht dargestellt werden. 

Das System 14 weist eine zentrale, relationale Datenbank 17 auf, die gleichzeitig 
den Hauptserver des Systems 14 bildet und mit einer Mehrzahl von Modulen 3 uber 
ein Netzwerk in Verbindung steht. Die Module 3 konnen jeweils entweder als Client 
Oder als Anwendungsserver mit angehangten Clients ausgebildet sein und bieten 
dem jeweiligen Nutzer uber GUIs oder Programmierschnittstellen die Moglichkeit, 
im voraus festgelegte Dienstleistungen aus dem Abrechnungs- oder Kundenverwal- 
tungsbereich in Anspruch zu nehmen. Die dazu notigen Datensatze sind in Tabel- 
len der zentralen Datenbank 1 7 gespeichert und werden von dort abgerufen. 

Aktive Mobil-Vermittlungsstellen (MSC: Mobile Switching Center) 32 ermitteln und 
speichern Gesprachsdaten wie Ursprung, Ziel, Dauer und Dienst von Mobiltelefona- 
ten. Die Informationen werden in das Abrechnungs- und Kundenverwaltungssystem 
14 eingelesen und dort von geeigneten Abrechnungsmodulen 20 bearbeitet, welche 
die Gesprachsgebiihren berechnen (Rating). Die dazu erforderlichen Daten werden 
aus der zentralen Datenbank 17 abgerufen, und nach Ablauf des Abrechnungspro- 
zesses werden die neu ermittelten Daten wieder in der Datenbank 17 gespeichert. 
Diese Daten konnen wiederum von einem Rechnungserstellungsmodul 22 abgeru- 
fen werden, mit dessen Hilfe der Provider die Kundenrechnungen erstellen kann 
(Billing). Die Kundenverwaltung als solche (Customer Care) wird ebenfalls anhand 
mehrerer Module, die jeweils far unterschiedliche Dienstleistungen verwendet wer- 
den, durchgefuhrt. Beispielsweise konnen uber ein Modul 24 Angaben uber freie 
Ressourcen an SIM-Karten-Verkaufer 34 weitergeleitet werden. Ebenso benotigt 
ein Provider Module 26 zur Abwicklung von Geldgeschaften mit Banken und Kre- 
ditkartenunternehmen 36 sowie Module 28 fur die Ubermittlung von Daten an ein 
Teilnehmerregister (HLR: Home Location Register) 30 des Mobilfunknetzes, in dem 
Daten von Teilnehmern gespeichert werden. 
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Alle Module 3 sind direkt mit der zentralen Datenbank 17 verbunden, konnen un- 
tereinander jedoch nicht uber direkte Schnittstellen komrnunizieren. Die Schnittstel- 
len zwischen den Modulen 3 sind ublicherweise uberhaupt nicht exptizit definiert. 
Statt dessen dient die zentrale Datenbank 17 als eine groBe implizite Schnittstelle 
zwischen alien verschiedenen Modulen 3, wodurch eine Vielzahl unnotiger intemer 
Unterabhangigkeiten verursacht wird. Die Schnittstelle wird demnach durch einen 
Satz an Datenbanktabellen dargestellt. In derartigen Systemen 14 wird die Daten- 
bank 17 auBerdem zumeist auch als Server dazu verwendet, die Geschaftslogik in 
den verschiedenen Modulen 3 zu konfigurieren, dient neben der Datenspeicherung 
zusatzlich als Schnittstelle zu externen Systemen und zur Kommunikation zwischen 
den Modulen 3. 

Im Telekommunikationsbereich sind in den letzten Jahren durch die rasante Ent- 
wicklung neuer Technologien (Handy, WAP-Handy etc.) extrem groBe Veiranderun- 
gen innerhalb kurzester Zeiten zu verzeichnen. Da zudem der Markt fiir den freien 
Wettbewerb geoffnet ist, werden potentielle Kunden (Subscriber) von vielen Anbie- 
tern (Providern) immer starker umworben. Daher ist es fur einen Provider unum- 
ganglich, VerSnderungen flexibel Rechnung zu tragen und schnell auf die Erfor- 
dernisse des Marktes einzugehen. Im selben MaBe steigen mit der Anzahl an 
Subscribern und der Vielfalt der technologischen Moglichkeiten auch die Anforde- 
rungen an Abrechnungs- und Kundenverwaltungssysteme. 

Nachteilig an den vorbekannten Systemen ist, dad fur Modifikationen oder Erweite- 
rungen bei Anderungen im Anspruchsprofil des Systemnutzers immer der Code 
des entsprechenden Systems geandert werden muB. Dadurch entstehen sowohl 
erhohte Personalkosten als auch eine enorme Verzogerung bei der Anpassung des 
Systems an die Markterfordernisse. 

Der vorliegenden Erfindung liegt daher die Aufgabe zugrunde, ein Abrechnungs- 
und Kundenverwaltungssystem, insbesondere fiir Kommunikationsdienste, zu 
schaffen, bei dem Anderungen oder Erweiterungen des Systems aufgrund gean- 
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derter Wunsche des Systemnutzers moglichst schnell mit moglichst geringem Pro- 
grammieraufwand durchgefuhrt werden konnen. 

Diese Aufgabe wird durch die Merkmale des Anspruchs 1 gelost. 

Dadurch, dafc das System eine verteilte Komponentenarchitektur aufweist, In der 
entsprechend den angebotenen Dienstleistungen Komponenten ausgebildet sind, 
die Qber Schnittstellen direkt miteinander kommunizieren kfinnen, wird eine flexible 
Konfiguration der Geschaftslogik ermoglicht, so da& Kundenwunschen mit einem 
Minimum an Implementationsveranderungen nachgekommen werden kann. Zudem 
laSt sich das System au&erst flexibel und leicht an eine ErhOhung der Anzahl der 
zu verarbeitenden Daten anpassen. 

Vorteilhafterweise ist das System in mindestens zwei hierarchisch angeordnete 
Schichten (Layers) mit zunehmendem Abstraktionsgrad unterteilt. Jede Schicht 
isoliert die iiber ihr liegende Schicht nach unten, so daB der daruberliegenden 
Schicht Implementierungsdetails der darunterliegenden Schichten verborgen blei- 
ben. In der bevorzugten Ausfuhrungsform des erfindungsgemSISen Abrechnungs- 
und Kundenverwaltungssystems ist das System unterteilt in Basisschicht (Base 
Layer), allgemeine Schicht (Common Layer), technische Unterstutzungsschicht 
(Technical Services Layer), Anwendungsschicht (Application Layer) und Ge- 
schaftsschicht (Business Layer). 

Besonders vorteilhaft macht es sich bemerkbar, dad das System in mindestens 
zwei hierarchisch angeordnete Ebenen (Tiers) entsprechend den technischen Auf- 
gaben unterteilt ist. In verschiedenen logischen Ebenen konnen Prozesse gleich- 
zeitig und unabhangig voneinander ablaufen; zudem ist eine noch feinere Eintei- 
lung in physikalische Ebenen moglich. In der bevorzugten Ausfuhrungsform des 
erfindungsgemaBen Abrechnungs- und Kundenverwaltungssystems ist das System 
unterteilt in Prasentationsebene (Presentation Tier), Anwendungsebene 
(Application Tier), Meta-Anwendungsebene (Meta-Application Tier), Domainebene 
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(Domain tier), Persistenzebene (Persistence tier) und Datenbankebene (Database 
Tier). 

Ober die Meta-Anwendungs-Ebene (Meta-Application Tier) werden einer Anwen- 
dung innerhalb des Systems vorteilhafterweise Mittel zur Verfugung gestellt, urn 
sich selbst zu beschreiben. Dies erlaubt eine dynamische (d.h. zur Laufzeit durch- 
fuhrbare) Konfiguration des Verhaltens der einzelnen Komponenten. 

Besonders vorteilhaft weist das System ein Meta-Anwendungs-Dictionary (Meta- 
Application Dictionary) auf, wodurch der Programmieraufwand bei Anderungen auf 
Serverseite sehr gering gehalten werden kann. 

In eihef vorteilhaften Weite^bilduhg~\A/eist~das System Einrichturigen auf,~die das 
Schnittstellenmodell des Servers auf der Clientseite zur Verfugung stellen und 
damit die eingesetzte Kommunikationstechnologie vor einem Client-Entwickler ver- 
bergen. 

Vorteilhafterweise bietet das System definierte Schnittstellen und Mechanismen zur 
Anfrageverteilung an, so dad mehrere gleichartige Anwendungsserver dem System 
hinzugeftigt werden konnen, wodurch die mogliche Anzahl an zu verarbeitenden 
Daten mit geringem Aufwand nahezu beliebig erhoht werden kann, ohne die Verar- 
beitungsgeschwindigkeit zu beeintrachtigen. 

Das System bietet in vorteilhafter Weise die Moglichkeit, Komponenten auszutau- 
schen Oder hinzuzufugen, so dali das System nicht veraltet und auf einfache Weise 
andere Oder zusatzliche Dienstleistungen anbieten kann, ohne daB das komplette 
System ausgetauscht werden muB Oder tiefgreifende Codeanderungen vorgenom- 
men werden miissen. Somit ist auch die Erstellung von Upgrades relativ kosten- 
gunstig und einfach. 
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Die Moglichkeit der Erweiterung von Klassen und/oder des Hinzufugens neuer 
Klassen liefert den Vorteil, eine Komponente wahrend der Ausfuhrung unter Ver- 
wendung von Meta-Anwendungs-Einrichtungen verandern zu konnen. 

Vorteilhafterweise wird die Arbeitsteilung innerhalb des Systems dadurch gefdrdert, 
daB die Datenbank in eine Vielzahl von unabhangigen Datenbankabschnitten auf- 
geteilt ist und/oder mehrere voneinander getrennte Datenbanken existieren, die 
jeweils mit lediglich einer Komponente kommunizieren. 

Vorteilhafl stellt das System Mechanismen zur Verfugung, die ein uber Komponen- 
ten verteiltes Transaktions- und Speichermanagement ermoglichen, wodurch die 
Robustheit und Zuverlassigkeit des Gesamtsystems sichergestellt wird. 

Weitere Einzelheiten, Merkmale und Vorteile der Erfindung ergeben sich aus der 
nachfolgenden Beschreibung unter Bezugnahme auf die Zeichnungen. Darin zeigt: 

Fig. 2 eine schematische Darstellung des Aufbaus einer Ausfiihrungsform des 



Fig. 3 eine schematische Darstellung der systeminternen Architektur einer be- 
vorzugten Ausfuhrungsform des erfindungsgemaBen Abrechnungs- und 
Kundenverwaltungssystems mit der Unterteilung in Schichten mit zuneh- 
mendem Abstraktionsgrad und in Ebenen entsprechend den technischen 
Aufgaben; 

Fig. 4 eine schematische Darstellung der Kommunikationsmoglichkeiten zwi- 
schen Servern und Clients in der bevorzugten Ausfuhrungsform des er- 
findungsgemaBen Abrechnungs- und Kundenverwaltungssystems von 



erfindungsgemaRen Abrechnungs- und Kundenverwaltungssystems; 



Fig. 3; und 
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Fig. 5 schematische Darstellungen des Aufbaus eines vorbekannten Systems, 
einer ersten unci einer zweiten Ausfuhrungsform des erfindungsgema&en 
Abrechnungs- und Kundenverwaltungssystems. 

In Fig. 2 ist ein schematisches Modell einer ersten Ausfuhrungsform des erfin- 
dungsgema&en Abrechnungs- und Kundenverwaltungssystems 1 dargestellt. In 
diesem System 1 dient eine Datenbank 7 lediglich zur permanenten Speicherung 
von Daten, die spater wieder abgerufen werden konnen. Die ubrigen oben genann- 
ten Funktionen von Datenbanken 17, die in vorbekannten Systemen 14 eingesetzt 
werden, werden nun groBtenteils von der Anwendungslogik ubernommen. Entspre- 
chend der jeweils angebotenen Dienstleistungen im Bereich des Abrechnungs- 

. bzw. Kundenverwaltungswesens sind Komponenten 5 ausgebildet, die miteinander 

uber gemeinsame Schnittstellen kommunizieren konnen und nicht die Datenbank 7 
als Schnittstelle verwenden mussen. Damit wird ein schnellerer Informationsaus- 
tausch zwischen den einzelnen Anwendungen ermoglicht, und durch die Abtren- 
nung der Anwendungslogik aus der Datenbank 7 eine Struktur erreicht, die flexibel, 
erweiterbar und ftlr eine Verarbeitung von grolien Datenmengen geeignet ist. Vejr- 
anderungen Oder Erweiterungen des Systems 1 konnen dabei ohne groRen Pro- 
grammieraufwand vorgenommen werden. Durch diese Struktur ist es mfiglich, je- 
des Problem nur einmal zu losen, und die Losung auf einfache Weise fur alle Kom- 
ponenten 5 des Systems 1 verfugbar zu machen. Gleichzeitig ist fur nahezu jede 
implementierte Losung sichergestellt, dali sie nicht nur ein bestimmtes festgelegtes 
Problem lost, sondern immereine Kategorie von Problemen. 

Zur besseren Verdeutlichung des Begriffs "Komponente" in der Praxis soil im fol- 
genden an einem Beispiel aus dem Telekommunikationsbereich die Aufteilung der 
Dienstleistungen im Bereich Kundenverwaltung in einzelne Komponenten 5 darge- 
stellt werden. Eine Moglichkeit der Einteilung des Systems 1 liefert etwa folgende 
Komponenten 5: 

Risk Management, 
Fraud Management, 
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Trouble Ticket Management, 
Address Management, 
Accounts Receivable, 
Document Management, 
Task Management, 
Order Management, 
Product Management und 
Inventory Management. 



Mit Hilfe der Komponente "Risk Management" kann der Systemnutzer die Kredit- 
wurdigkeit von Kunden uberprufen. Die Komponente "Fraud Management" wird zur 
Betrugsdetektion eingesetzt. Aufgedeckt werden dabei UnregelmalJigkeiten Oder 
starke Abweichungen vom ublichen Verhalten des Kunden, etwa wenn eine hone 
Anzahl an Auslandsgesprachen bei einem Kunden festgestellt wird, der bisher nie 
ins Ausland telefoniert hat. In der Komponente "Trouble Ticket Management" wer- 
den Beschwerden von Kunden und Storungsmeldungen vom Netz selbst registriert 
und bearbeitet. Mit Hilfe der Komponente "Address Management" wird ein Adress- 
register verwaltet, das die Prufung der Plausibility einer Adresse erlaubt. Die Kom- 
ponente "Accounts Receivable" kann als eine Art Schuldbuchhaltungskomponente 
aufgefaBt werden. Mit ihrer Hilfe werden Zahlungseingange registriert. offene 
Rechnungen aufgedeckt und Konten ausgeglichen. Die Komponente "Document 
Management" steht zur Verwaltung von Kundendokumenten (Briefe, Faxe etc.) 
bereit. Durch die Dienstleistungen der Komponente "Task Management" werden 
nach Eingang von Auftragen die entsprechenden ArbeitsauftrSge erteilt. Die Kom- 
ponente "Order Management" ist fur Auftragsbearbeitung und Kundenveiwal- 
tungsdienstleistungen zustandig. Mit Hilfe der Komponente "Product Management" 
kann der Endverbraucher uber die Verfiigbarkeit von Produkten und uber Preisli- 
sten informiert werden. Die Komponente "Inventory Management" ist fur die Be- 
standsfuhrung zustandig, d.h. mit ihrer Hilfe ist eine Verwaltung der vergebenen 
und freien Telefonnummern, SIM-Karten oder anderer Gegenstande moglich. Jede 
der genannten Komponenten 5 erfullt eine relativ groSe Anzahl an Dienstleistun- 
gen. Wie bereits oben erwahnt kennen die Komponenten 5 uber direkte Schnittstel- 



4132P0794EP 



31-03-2000 



len Daten untereinander austauschen. Wenn also beispielsweise die Komponente 
"Accounts Receivable" spezielle Kundendaten benotigt, greift sie nicht mehr auf 
Daten aus der Datenbank zuriick, sondern erhalt die erforderlichen Daten direkt 
von der Komponente "Order Management" oder entsprechenden anderen Kompo- 
nenten. 

Das Komponentenmodell fur ein Abrechnungs- und Kundenverwaltungssystem 1 
setzt voraus, daB eine grundlegende Funktionalitat in einem zentralisierten Frame- 
work 10 verfugbar ist. Jede einzelne Komponente 5 ist von alien anderen Kompo- 
nenten unabhangig. Allerdings sind die Komponenten angewiesen auf einen Satz 
von Dienstleistungen, um korrekt arbeiten zu konnen. Diese benotigten Dienstlei- 
stungen konnen auch von Komponenten anderer Hersteller geliefert werden. Dann 
ist es moglich, diese in ein System mit den systemeigenen Komponenten zu inte- 
grieren. 

Das vorliegende System 1 ist jedoch nicht als rein dienstleistungsbasierendes Mo- 
dell ausgebildet, sondern weist auch etliche Elemente eines eher objektorientierten 
Modells auf. Auf Einzelheiten wird spater noch genauer eingegangen. 

Es existieren zahlreiche Definitionen des Begriffs "Komponente" in der objektorien- 
tierten Programmierung. Diejenige. die den in der Praxis im vorliegenden Abrech- 
nungs- und Kundenverwaltungssystem 1 verwendeten Komponenten 5 am nach- 
sten kommt, lautet: 

"Eine Komponente ist eine Konstruktionseinheit mit vertraglich spezifizierten 
Schnittstellen und (wenn moglich) lediglich expliziten Kontextabhangigkeiten. Eine 
Softwarekomponente kann unabhangig eingesetzt werden und ist Gegenstand fur 
eine zusammengesetzte Konstruktion mit Produkten Dritter. " 

Die Hauptaspekte dieser Definition sind, daB eine Komponente 5 unabhangig von 
anderen Komponenten aufgestellt und eingesetzt werden kann, dali eine Kompo- 
nente 5 von anderen Anbietern verwendet werden kann, um Abrechnungs- oder 
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Kundenverwaltungssysteme zu bilden, und dad eine Komponente 5 lediglich 
Schnittstellen beinhaltet, d.h. keinen Zustand im iiblichen Sinne des Wortes auf- 
weist, obwohl eine Komponente 5 Eigenschaften haben kann und bestimmte ex- 
plizite Anspruche innerhalb eines Kontexts an ihren Einsatz stellt. 

Die Komponenten 5 im vorliegenden System 1 sind in der Regel relativ umfassend. 
Das folgt daraus, daB eine Komponente 5 unabhangig innerhalb eines bestimmten 
Kontexts eingesetzt werden kann und daher ausreichend abgeschlossen sein muB. 
Allerdings sind auch Komponenten 5 mit lediglich einer Schnittstelle moglich. 

Komponentenschnittstellen sind in erster Linie dienstleistungsbasierend. Unter der 
Voraussetzung, dad eine Komponente 5 keinen Zustand besitzt, liefern die 
Schnittstellen, die von einer Komponenteninstanz geschaffen werden, Dienstlei- 
stungen und senden keine Information uber den Status der Komponente 5 zuruck. 
Die Anzahl der Dienstleistungen bzw. Schnittstellen, die von einer Komponente 5 
geliefert werden, muli der Zahl entsprechen, die nfitig ist, urn den Satz an Verhal- 
ten vollstandig zu verdffentlichen, der innerhalb der Komponente 5 zusammenge- 
faBt ist. 

Wie bereits oben erwahnt, verwendet das vorliegende Komponentenmodell in er- 
ster Linie Dienstleistungen, insbesondere urn den Einsatz von Komponenten 5 mit 
Komponenten anderer Hersteller zu ermoglichen. Andererseits verwendet das vor- 
liegende Abrechnungs- und Kundenverwaltungssystems 1 zwischen den fur dieses 
System entwickelten Komponenten 5 zusatzlich eine traditionellere, objektorientier- 
te Modellmdglichkeit, bei der Komponenten 5 ihre intemen Klassen fur den Ge- 
brauch durch andere Komponenten veroffentlichen, was eher einer Peer-to-Peer- 
Architektur entspricht. 

Urn Clients direkten Zugang zu den Objekten innerhalb einer Komponente 5 und 
deren Benutzung zu ermoglichen, wird eine zusatzliche Losung mit Peer-to-Peer- 
Objekten angeboten, so daB GUI-Entwickler auf einfache Weise mit modernen 
Werkzeugen arbeiten konnen, die auf einem model-view-artigen Pattern basieren. 



4132 P 0794EP 



31-03-2000 



.^ie Komponenten 5 existieren also als einzelne abgeschlossene Einheiten inner- 
halb eines Systems. Die technische Grundlage fur Ausfuhrung und Kommunikation 
wird durch ein Framework 10 geliefert. Das Framework 10 ist Teil des gesamten 
Systems 1, das durch die geschaftsspezifische Logik komplettiert wird. Details uber 
die Architektur des Systems 1 werden in der Beschreibung zu Fig. 3 erlautert. 

Komponenten 5 kommunizieren miteinander, wobei sie veroffentlichte Dienstlei- 
stungen verwenden, besttzen aber ebenso Anforderungen an den Kontext, d.h. das 
ganze Verhalten, auf das eine Komponente 5 angewiesen ist, und das nicht in der 
Komponente 5 selbst implementiert ist, kann von anderen Komponenten Oder vom 
Framework stammen. Ein Hauptmerkmal des Frameworks betrifft die Abgeschlos- 
senheit, d.h. das Framework liefert den Behalter fur die Ausfuhrung einer Kompo- 
nente 5. AuRerdem erlaubt die Struktur des Komponentendesigns das einfache 
Packen von Anwendungselementen zum Zwecke der Abgeschlossenheit. 

Die Struktur der Komponentensoflware ist daher folgendermaften: Geschaftsdo- 
mainklassen werden in Pakete gruppiert, wobei ein Paket eine relativ feine logische 
Domain darstellt. Diese Pakete werden in Komponenten 5 gruppiert, so daft Pakete 
in einer Komponente 5 Klassen enthalten, die sich bis zu einem gewissen Grad 
gegenseitig benutzen, wahrend Pakete in getrennten Komponenten 5 sich gegen- 
seitig so wenig wie moglich benutzen. Schlieftlich werden Komponenten 5 zusam- 
men in Servern gruppiert. Diese Gruppierung kann freigestellt sein, wobei es gun- 
stig ist, wenn Komponenten 5, die oft miteinander kommunizieren, im selben Server 
zusammengefaflt sind. Zur Verbindung mit fremden Frameworks ist es notig, so 
viele Abhangigkeiten als moglich zwischen der Ausfuhrungsumgebung und einer 
Komponente 5 zu entfernen. Daher benotigt jede Komponente 5 ihre eigene globa- 
le AbstractFactory-lnstanz; dies kann nicht pro Server geschehen, da es nicht ga- 
rantiert ist, daB die Komponente 5 innerhalb dieses Servers laufen wird. 

Eines der Hauptkonzepte im Framework, die es zu einem Komponentenframework 
machen, ist die AbstractComponent-Klasse. Diese Klasse beinhaltet die Attribute 
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und das Verhalten, die alien Komponenten 5 gemeinsam sind. Spezifische Kompo- 
nenten 5 sind Unterklassen dieser Klasse. Da die Dienstleistungen, die von einer 
Komponente 5 geliefert werden, in Transaktionen involviert sind, und vielfache 
Komponentendienstleistungen in einer Transaktion verwickelt sein konnen, ist die 
AbstractComponent-Klasse transaktional. 




Die Unterklassen der AbstractComponent- Klasse, die eigentlichen Komponenten 5, 
enthalten a lie Dienstleistungen, die fur die Komponente 5 spezifisch sind. Ein wei- 
teres wesentliches Merkmal jeder Unterklasse ist eine Instanz einer Fassadenklas- 
se fur jede externe Komponente, mit der die Komponente 5 kommuniziert. 



Dienstleistungen an den Komponentengrenzen bzw. Dienstleistungen, die in ande- 
ren Komponenten implementiert sind, werden intern mittels Fassadenobjekten mo- 
delliert. Die Dienstleistungen in den Fassaden sind diejenigen, die die Komponente 
5 benotigt, um zu funktionieren. Beispielsweise weist Komponente M A M intern eine 
"B"-Fassadeninstanz und eine "C"-Fassadeninstanz auf, wenn sie Schnittstellen in 
den Komponenten "B" und "C" verwendet. Das Design und die Implementation der 
Komponente "A" konnen dann groBtenteils unabhangig von den Komponenten "B" 
und "C" ausgefuhrt werden. Wenn die Komponenten 5 eingesetzt werden, mussen 
die Dienstleistungen in den Fassaden in geeignete Dienstleistungen in anderen 
Komponenten abgebildet werden. 



In einer bevorzugten Ausfuhrungsform des Abrechnungs- und Kundenverwaltungs- 
systems 1 sind diese Fassaden derart implementiert, daB das Mappen einer Fas- 
sadendienstleistung zu einer eigentlichen Komponentendienstleistung ohne Ande- 
rung des Codes ausgefuhrt werden kann. Aus diesem Grund existiert eine abstrak- 
te Klasse, die generelles Verhalten beinhaltet, die AbstractFacade-Klasse. Sowohl 
fiir veroffentlichte Domainobjekte als auch fur Komponenten 5 unterstutzt das Fra- 
mework 10 Transaktionen zwischen Komponenten 5. Fur Dienstleistungspropaga- 
tion von Komponente zu Komponente wird implizite Propagation verwendet. Im 
Bereich Speicherverwaltung werden die Transaktionskontexte fur nicht transakti- 
onsbezogene Zwecke verwendet. 
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Zusammenfassend IM. sich nochmals festeteiien. da* d te hfer dargesteIKe bevo, 
zuflt e Aus.Ohrungs.orm des Abrechnungs- und Kundenverwaitungssystems 1 z m 
el Die—gen in Komponentenfassaden verwende,, wenn D,ens t te«<un 
gen «r externa Komponenten geiiefer, warden mOssen. Ebenso «MM 
jedoch Komponenten 5 ihre internen Klassen «r die BenuUung durch andere sy- 
steminterne Komponenten 5. 

,„ Fig 3 is, die Einteilung des Systems 1 in hierarchy angeordnete Schichten 
(L ayers> mi, zunehmendem Abs,rak»onsgrad und in Ebenen (Tiers) 
en LLd-n Aufgaben unterte.. Die Schichten und Ebenen in der Arcb eK^ 
des Systems 1 liefern eine zweidimensionale Mate. Ailerdings is, d,ese Unterte.- 
.ung in deTpakete^^^ - 

Jed e Scbich, (Layer) is, von den kompiizterten Beiangen der darunteriiegenden 
Schichten isoiiert. so da R eine Kommunika,ion zwischen den Schichten nur mrfteis 
Benutzung von Standardschnittstellen implemen,ier, wird. Dadurch wrd e,n hoher 
Grad an Flexibilila, und Unabhangigkeit gewahrieistet. y : 

,„ einer bevorzugten Aus.Ohrungs.orm is, das System 1 in fun. Schichten unterteM. 
Die unterste Baslsschich, (Base Layer) 40 beinhalte, dabei Klassen. d« grundte- 
gendes Verhaiten iietern. wie Systemressourcen. Bemebssystem und hardware- 
spezif,sche Ktossen. Die Schicht beinhaite, auch das Verhaiten, das von benutzter 
Drittsoftware erlang, wird. In der bevorzugten Aus.uhrungs.orm sind hterbennsbe- 
sondere die Grundlagen von CORBA, einer gemelnsamen Stendardarchtektur .ur 
Obiek,an.orderungsvermittter, sowie von TopLink. einer objektebezogenen Bnnch- 
,ung zum Abbiiden, beinhalte,. Als Programmiersprache wird in dieser Ausfuh- 
rungsform Java verwendet. 

,„ der darOber angeordneten allgemeinen Schich, (Common Layer) 42 sind Ab- 
straktionen von Klassen der Basisschich, 40 sowie Klassen beinhalte,. die al^e- 
meine Einrichtungen ,ur alle Schichten und Ebenen liefern. Darin sind auch Ele- 
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mente for das M «p ro ,o k c,„ere„ (Logging, und f0r die Fehlerbehand|ung ^ 
handling) beinhaltet. 

Daraber angeordne, is, die technische Unterstutzungsschich, (Technical Services 
Layer, 44, die Klassen beinhaltet, die software-technische Dienste anbiete,. 

Die darOber liegende Anwendungsschich, (Application Layer, 46 enthai, a»e Klas- 
sen und das Verhaiten far eine dynamische DenniHon der E te me„,e einer Anwen- 
dung bzw. einer Komponente 5 auf einem Mete-Level. Instenzen dieser Klassen 
werden be! InteraWionen mi, einer echten Anwendung verwende,. Die Dienste der 

,echn,sche„ Un,e re ,utzungsschich, 44 werden zu einer abstrakten Anwendung zu- 
sammen ge fe Bt und Mecnanfemen ^ ^ 

Tssen d r h Me,a - Ebe " e ertauM Dfe Anwendungsschich, 46 beinhaite, die 
Klassen d re den hachsten Level an Abs.raK.icn in, System reprasenleren be, 
sp^weKe d fe Factory, die verschiedene D fe „s,,eis,ungen vcn den darunte^ 
Senden Schichten verwende,. wie etwa Transa kUo „s- und Persistence.,^ 

Die Gesamthei, der Bemente von der Basisschich. 40 bis hln zu Teilen der An- 
wendungsschich, 46 *ann auch a te ( .ech„isches, FrameworK ,0 bezelchne. war- 
den. Ers durch die Geschsmsschich, (Business Layer, 50, die d* spezifischen 
Klassen tur das Verhalten einer Anwendung und einer Komponente 5 e„,h a „ „ 

1 w TdT h ' tehen ~*"~«»" Vorgange programme Je" 
den, wird das System 1 komplettiert. 

Durch dte ,so«,„„ der einzeinen Schichten M realist, da 8 beispteisweise die 
Ta g ke „ e,nes Business-LogiX-EmwicMers nich, vcn einer Andarung i„ einer darun 
.erl,egenden Schfch, (e^va einer Anderung das Be.riebssys.ems, bl„„„ R , 2 

Das System , is, zudem in verschiedene Ebenen (Tiers, unterteilba, Dabe, is, zwi- 
sch- -er Au«e„ung in icgfcche und physfcaiische Ebenen zu unterscheiden. Die 
Aufteilung des Systems in zwei iogische Ebenen (dic ke Clients, bzw. drei fcgische 
Ebenen (dOnne Ciiente, wird vorgenommen, da In verschiedenen icgischan Ebl„ 
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Verarbeitungsprozesse unabhangig voneinander und gleichzeitig ablaufen konnen. 
In der vorliegenden bevorzugten Ausfuhrungsform ist das System zudem in eine 
feinere Ebenenstruktur nach physikalischen Ebenen unterteilt. 

Die oberste und damit die dem Systemnutzer nachste Ebene ist dabei die Prasen- 
tationsebene (Presentation Tier) 52. Obwohl der Server eigentlich nicht mit der 
Prasentationsebene 52 in Verbindung steht, mulS sein Framework 10 dennoch eini- 
ge Einrichtungen liefern, mit denen die Objekte der Prasentationsebene 52 kom- 
munizieren konnen, und zudem bestimmen, wie prasentationsspezifisches Verhal- 
ten behandelt werden mull. Die Elemente der Presentation betreffen die Reprasen- 
tation von Informationen, die Navigation durch diese Informationen und deren Ma- 
nipulation. Das Framework 10 des Servers setzt die Verwendung einer objektorien- 
_ tierten Anwenderschnittstelle voraus und liefert entsprechendeEinrichtungen. Die- 
Elemente der Prasentationsebene 52 verwenden die beschreibende Information, 
die in Meta-Anwendungs-lnstanzen geliefert wird, urn Aspekte zu definieren, wie 
Geschaftsobjekte und ihre Attribute betrachtet oder verwendet werden sollen. Die- 
se Meta-Anwendungs-lnformation liefert eine Isolationsschicht zwischen den Pra- 
sentationsobjekten (Fenstern) und Anwendungs- oder Geschaftsobjekten. Eine 
zusatzliche Isolationsschicht kann durch Zugangsprivileg-Einrichtungen erreicht 
werden, die Serverelemente zeigen oder verstecken. 

Die Anwendungsebene (Application Tier) 54 beinhaltet Klassen und Schnittstellen, 
die die Anwendung reprasentieren, sowie Klassen, die auf Anwendung bezogenes 
Komponentenverhalten in Pakete packen. Enthalten sind eine Anzahl von Klassen, 
die fur die Interaktion mit einer Anwendung notwendig sind, sowie die fundamental 
abstrakte Klasse fur Anwendungskontrollklassen und Anwendungsprozeliklassen. 
Diese Klassen bilden die Hauptschnittstelle fur Clients innerhalb der Applikationen. 
Sie liefern die fundamentalen Mechanismen fur Kommunikation mit der Applikation, 
indem sie Instanzen von gewunschten Objekten erzeugen, und erlauben die Navi- 
gation zu diesen Objekten. 
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Zusammenfassend lafit sich deshalb vereinfacht sagen, dad die Anwendungsebe- 
ne 54 die Klassen enthalt, die Geschaftsprozesse modellieren, welche zugrunde- 
liegende Geschaftsobjekte verwenden. Der GroSteil der individuellen Einstellungs- 
arbeit ist daher in dieser Ebene isoliert. 



Zudem enthalt die Anwendungsebene 54 die Fassadenobjekte, die die Hauptein- 
richtungen fur die Kommunikation zwischen Komponenten 5 darstellen. 

Die Klassen in der Meta-Anwendungsebene (Meta-Application Tier) 56 liefern einer 
Anwendung Einrichtungen, um sich selbst zu beschreiben und zu andern. Die Me- 
ta-Anwendungsebene 56 besteht aus Klassen, die die Definition von Informationen 
bezuglich Aspekten von Anwendungsobjekten und Domainobjekten erlauben. Die- 
se Klassen machen es moglich, Aspekte von Geschaftsobjekten dynamisch auf 
einem Meta-Level zu konfigurieren. Solche Aspekte beinhalten die Betitelung von 
Klassen, beinhalten weiter Formatmasken und Langen fur Attribute, beinhalten In- 
formationen, ob bestimmte Attribute obligatorisch sind usw. 

Die Meta-Anwendungs-Einrichtungen liegen auf einem hoheren Level als die An- 
wendungen und liefern generelle Funktionalitat, die auf alle Anwendungen an- 
wendbar ist. 



Die Domainebene 58 weist die Geschaftsobjektklassen (business object classes) 
einer spezifischen Anwendungsdomain auf. In anderen Worten ist die Domainebe- 
ne 58 die Ebene, die als einzige Klassen beinhaltet, welche die Geschaftsdorrtain 
einer Anwendung modellieren. Daher beschrankt sich der Arbeitsbereich fur An- 
wendungsentwickler groBtenteils auf diese Ebene. 

Die Domainebene 58 besteht nahezu ausschlieRlich aus einer abstrakten Domain- 
klasse, von der alle Geschaftsobjekte ihr Verhalten vererbt bekommen. Zudem 
enthalt die Domainebene 58 Domainklassen, die jeweils Unterklassen der oben 
genannten abstrakten Klasse darstellen. Diese Klassen modellieren stabiles, nicht 
veranderliches Verhalten der zentralen Klassen einer Problemdomain. Jedes un- 
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bestandige Verhalten, das eine Domainklasse betrifft, ist in Klassen zusammenge- 
falit, die der Anwendungsebene 54 zugerechnet werden, aber durch die Domain- 
klassen benutzt werden. 

Die Persistenzebene (Persistence Tier) 60 ist die Ebene, die die Interaktionen zwi- 
schen Domainobjekten und einem persistenten Speicher zusammenfaftt. Somit 
beinhaltet sie das Verhalten, das Persistenz fur Objekte liefert, namlich ihre Spei- 
cherung und das Abrufen. Die Ebene beinhaltet ebenso die Klasse, die die Verbin- 
dungen mit der Datenbank 7 verwaltet. Insgesamt stellt sie zum einen eine Abbil- 
dung des Klassenmodells der Domainebene 58 auf das Datenmodell der Daten- 
bank 7 dar und zum anderen unterstQtzt sie Mechanismen zur transaktionsgesi- 
cherten Manipulation der Daten in der Datenbank 7. 

Die Funktionen der Datenbankebene 62 wurden bereits oben ausfilhrlich beschrie- 
ben. 

Die verschiedenen Variationsmoglichkeiten auf Server- bzw. Clientseite mit dem 
Ziel von Veranderungen oder Erweiterungen des Systems 1 lassen sich am besten 
anhand des Schemas in Fig. 4 verdeutlichen. Aufbauend auf dem Framework 10 
sind Clientseite 70 und Serverseite 71 gesondert abgebildet. Auf der Serverseite 71 
sind die Geschaftsschichtobjekte 72, die Anwendungsschichtobjekte 74 und die 
Meta-Anwendungsschichtobjekte 76 anskizziert. Auf Clientseite 70 sind die erfor- 
derlichen Schnittstellen 66, insbesondere GUIs, ebenso enthalten wie speziell aus- 
gebildete JavaBeans 68. Die Pfeile skizzieren die jeweiligen Wechselwirkungsm6g- 
lichkeiten zwischen Client und Server bzw. innerhalb des Clients. 

Durch die spezifisch ausgebildeten JavaBeans 68 konnen auf Clientseite 70 vorge- 
fertigte GUI-Einrichtungen erzeugt werden, so dad der Systemnutzer Qber Benut- 
zerschnittstellen Einstellungen vornehmen kann, wodurch der Programmierauf- 
wand reduziert wird. Durch ihre Verwendung ist es moglich, das Schnittstellenmo- 
dell des Servers auf Clientseite 70 zur Verfugung zu stellen und damit die einge- 
setzte Kommunikationstechnologie vor einem Client-Entwickler zu verbergen. 
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Somit bekommt der Systemnutzer Schnittstellen zur Verfiigung, an denen er sich 
anhangen kann, urn seine SonderwiJnsche zu implementieren. Dies geschieht an 
speziellen lokalisierten Stellen, so daB kein grundlegender Code geandert werden 
muS. 

Besonders hilfreich bei der DurchfQhrung dieses Vorhabens ist das Meta- 
Anwendungs-Dictionary. Dieses beinhaltet eine grofte Menge an Informationen 
iiber eine Anwendung, ihre Klassen und die Attribute in den Klassen, weshalb das 
Meta-Anwendungs-Dictionary die dynamische Konfiguration von Anwendungsin- 
formationen und Verfahrensablaufen auf einem Meta-Level erlaubt. Das eigentliche 
Dictionary wird durch eine Instanz reprasentiert, die als Root des Dictionary's fun- 
giert und zusatzlich Informationen iiber die Anwendung als solche beinhaltet. Des 
weiteren beinhaltet das Dictionary den Satz von Instanzen, die Meta-lnformationen 
fur Klassen definieren. 

Durch das Meta-Anwendungs-Dictionary wird also eine Menge von Eigenschaften 
festgelegt, die fur jede Klasse im Server gelten. Somit ist eine Erweiterung bzw. 
Veranderung des Verhaltens des gesamten Systems 1 wShrend der Laufzeit mog- 
lich, ohne den bestehenden Code andern zu miissen. Diese Erweiterungen werden 
implementiert, indem sie von den Geschaftsklassen, die im Server aufgefilhrt wer- 
den, abgeleitet werden Oder als neue Klassen hinzugefugt werden. Die neuen 
Klassen werden in den Server konfiguriert, indem die Meta-Anwendungs- 
Einrichtungen des Servers verwendet werden. Diese Unterklassen konnen die 
meisten der existierenden Methoden iiberschreiben und haben daher die Moglich- 
keit, die bestehende Funktionalitat zu verandem oder zu erweitern. 

Fig. 5 zeigt eine schematische Darstellung der Entwicklung von den vorbekannten 
Systemen 14 zu einer ersten und einer zweiten Ausfuhrungsform des erfindungs- 
gemafcen Abrechnungs- und Kundenverwaltungssystems 1. Die in Fig. 5 vorge- 
nommene Einteilung der Systeme in drei logische Ebenen fur Prasentationslogik 
82. Anwendungslogik 80 und Datenbank 84 ist dabei lediglich als Hintergrund fur 
die bisher beschriebene Einteilung des erfindungsgema&en Abrechnungs- und 
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Kundenverwaltungssystems 1 in physikalische Ebenen anzusehen, von denen wie 
erwahnt bevorzugterweise mehr als drei existieren konnen. 

In den vorbekannten Systemen 14 bildeten Prasentationslogik 82, Anwendungslo- 
gik 80 und Datenbank 17 jeweils einen groBen Block mit entsprechenden Kommu- 
nikationsmoglichkeiten, die zu Fig. 1 bereits ausfuhrlich erlautert wurden. Im erfin- 
dungsgemaften System 1 ist es nun nicht nur moglich, die Anwendungslogik 80 
entsprechend den angebotenen Dienstleistungen zu separieren, vielmehr ist es 
auch denkbar, dall die Datenbank 7 selbst in logisch getrennte Datenbankabschnit- 
te 12 aufgeteilt wird, anstelle einen grofcen monolytischen Block zu bilden und/oder 
daB mehrere voneinander getrennte Datenbanken 12 existieren. Jeder Datenban- 
kabschnitt und/oder jede getrennte Datenbank 12 ist dann genau fur eine Kompo- 
nente 5 zustandig, der sie Daten liefert und von der sie Daten abspeichert. 

Durch das vorliegende Abrechnungs- und Kundenverwaltungssystem 1 ist es mog- 
lich, weitere Anwendungsserver entsprechend bereits vorliegenden Servern zu re- 
produzieren und parallel zu diesen einzusetzen. Dadurch ist das Abrechnungs- und 
Kundenverwaltungssystem 1 auch fur Systemnutzer mit einigen Millionen abzu- 
rechnender Kunden und einer hohen Anzahl an Transaktionen geeignet. 

AuBerdem stellt das System 1 Mechanismen zur Verfugung, die ein uber die Kom- 
ponenten 5 verteiltes Transaktions- und Speichermanagement ermoglichen. 

Das oben dargestellte bevorzugte Modell des Abrechnungs- und Kundenverwal- 
tungssystems 1 ist lediglich als bevorzugte Ausfuhrungsform aufzufassen, denkbar 
sind jedoch viele Abwandlungen von dieser speziellen Ausfuhrungsform. So ist bei- 
spielsweise die Anzahl der Schichten und Ebenen nicht exakt durch die in obigem 
Beispiel beschriebene Anzahl definiert, sondern kann beliebig nach oben oder un- 
ten variiert werden, solange die Unterteilung in mindestens zwei Schichten und 
mindestens zwei Ebenen beibehalten wird. Das System 1 la&t sich auch beliebig 
auf dunne oder dicke Clients anwenden. Die genaue Aufteilung in Komponenten 5, 
die zu Fig. 1 erlautert wurde, ist ebenso lediglich als Beispiel aufzufassen. Dem- 
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nach konnen auch andere Dienstleistungen des Abrechnungs- und Kundenverwal- 
tungssektors zu einer entsprechenden Komponente 5 zusammengefalJt werden, 
solange die allgemeinen Kriterien fur eine Komponente 5 erfullt werden. Auch die 
Verwendung von Java, CORBA und TopLink ist lediglich eine Frage des aktuellen 
Marktangebots; genauso ist es denkbar, andere Produkte mit ahnlichen Eigen- 
schaften fur die vorliegenden Zwecke einzusetzen. 

Besonders sei darauf hingewiesen, daS das Abrechnungs- und Kundenverwal- 
tungssystem 1 nicht auf den Einsatz im Telekommunikationsbereich beschrankt ist. 
Vielmehr ist es durchaus meglich, das System 1 in der gesamten Verbraucherin- 
dustrie (Strom, Wasser, Gas, Internet etc.) einzusetzen bzw. Teile des Systems 1 
zur reinen Kundenverwaltung in Betrieben zu verwenden. 
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1. Abrechnungs- und Kundenverwaltungssystem (1), insbesondere fur Kom- 
munikationsdienste, mit 

mindestens einer Datenbank (7), in der Daten gespeichert und abgerufen 
werden konnen, und die bevorzugterweise als Server ausgebildet ist, 

einer Mehrzahl von Clients, die mit der mindestens einen Datenbank (7) 
kommunizieren, und/oder mindestens einem Anwendungsserver mit zuge- 
horigen Clients, der mit der mindestens einen Datenbank (7) kommuniziert, . _ 
und 

einem entsprechenden Framework (10), 

wobei dem Benutzer des Systems (1) entsprechende Dienstleistun- 
gen gemaft den jeweils gewunschten Abrechnungs- Oder Kunden- 
verwaltungsvorgangen zur Nutzung pffen stehen, 

dadurch gekennzeichnet, daft 

das System (1) eine verteilte Komponentenarchitektur aulweist, in der ent- 
sprechend den angebotenen Dienstleistungen Komponenten (5) ausgebildet 
sind, die uber Schnittstellen direkt miteinander kommunizieren konnen. 

2. Abrechnungs- und Kundenverwaltungssystem (1) nach Anspruch 1, dadurch 
gekennzeichnet, daft das System (1) in mindestens zwei hierarchisch ange- 
ordnete Schichten (Layers) zunehmenden Abstraktionsgrades unterteilt ist, 
wobei die jeweils nachstuntere die uber ihr liegende Schicht nach unten iso- 
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Iter,, so daa .mpiemenrierungsdetails der unteriiegenden Schichten den da- 
rubertegenden Schichten verborgen bleiben. 

>• 2r*" maS ~ KU " denreiWa « u "Sssys t e m „, nach Anspruc „ , ^ 2 
dadurch gefcennzeichne.. da6 das System (1) h 

ch,sch angeordnete Ebene „ en(spreohend ^ - 

ben u nte r, em ist . wobei dte Elemente a „ er Ebenen zu ^ 
von der Speicherur* bis 2ur Prasentation der Daten J^"*" 

Abrechnungs- und Kundenve^aitungssystem („ „ ac „ einem der AnsprO- 

ZH b 7 9ekennzeichne, • da6 das s ^ < 1 > - 

Abrecbnung,. und Kundenverwai.ungssys.em (1) nach einem ^ 

cbe 1 *s 4 . dadurcn g ekennzeichne , daB ^ £ P- 

^•s S ch,ch. (40, angeord nete allgemeIne ^ ^ ^ 

*. Absfrattionen von Kiassen d er Basisschich, ,40, und K^n 
be,nha,.e, die aiigemeine Einrkhlungen m a „ e ^ ^ 

r h KUnd ~ ,U "~ nach einem 
Che 1 b,s 5, dadurch gekennzeichne., d aR das System ,1, e ,„e Ober der M- 
aemeinen Schich. (42, angeordnete technfcche UntersUMzungss Lh, 

a?;:r uyer> m - «*-~~ .c 

cheTb^TdT K ; nden " S ™ a,tUn ~ d> -h einem der AnsprO- 
che 1 b« 6. dadurch geKennzeichne., da K das System („ eine Ober der 
echn,schen UntersKKzungsschich, (44, an8eordnete Anw ndung ^ c ' 

srrr m — * d, ° * — - — — ~ 

zungssch^h, (44, zu e.ner abs,r ak ,en Anwendung zusammenfeB, sowie 
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Mechanismen zur Beschreibung der Elemente der Domainebene (58) auf 
einer Meta-Ebene erlaubt. 

8. Abrechnungs- und Kundenverwaltungssystem (1) nach einem der Anspru- 
che 1 bis 7, dadurch gekennzeichnet, daft das System (1) eine uber der 
Anwendungsschicht (46) angeordnete Geschaftsschicht (Business Layer) 
(50) aufweist, die die domainspezifischen Klassen fur jede Komponente (5) 
beinhaltet 

9. Abrechnungs- und Kundenverwaltungssystem (1) nach einem der Anspru- 
che 1 bis 8 f dadurch gekennzeichnet, daft das System (1) eine Prasentati- 
onsebene (Presentation Tier) (52) aufweist, die die Presentation der Daten 
und Funktionen der Anwendung fur den Systemnutzer implementiert. 

10. Abrechnungs- und Kundenverwaltungssystem (1) nach einem der Ansprti- 
che 1 bis 9, dadurch gekennzeichnet, dad das System (1) eine Anwen- 
dungsebene (Application Tier) (54) aufweist, die Klassen sowie Schnittstel- 
len beinhaltet, die die Anwendung reprasentieren. 

11. Abrechnungs- und Kundenverwaltungssystem (1) nach einem der AnsprU- 
che 1 bis 10, dadurch gekennzeichnet, daft das System (1) eine Meta- 
Anwendungsebene (Meta-Application Tier) (56) aufweist, in der Klassen 
beinhaltet sind, die einer Anwendung Mittel liefern, um sich selbst zu be- 
schreiben. 

12. Abrechnungs- und Kundenverwaltungssystem (1) nach einem der Ansprii- 
che 1 bis 11, dadurch gekennzeichnet, daft das System (1) eine Domaine- 
bene (Domain Tier) (58) aufweist, die die Geschaflsobjektklassen (business 
object classes) einer spezifischen Anwendungsdomain beinhalten. 

13. Abrechnungs- und Kundenverwaltungssystem (1) nach einem der Anspru- 
che 1 bis 12, dadurch gekennzeichnet, daft das System (1) eine Persi- 
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16. 



17. 



18. 



stenzebene (Persistence Tier) (60) aufweist, die zum einen eine Abbildung 
des Klassenmodells der Domainebene (58) auf das Datenmodell der min- 
destens einen Datenbank (7) darstellt und zum anderen Mechanismen zur 
transaktionsgesicherten Manipulation der Daten in der mindestens einen 
Datenbank (7) unterstQtzt. 

• Abrechnungs- und Kundenverwaltungssystem (1) nach einem der Anspru- 
che 1 b,s 13, dadurch gekennzeichnet, daS das System (1) ein Meta- 
Anwendungs-Dictionaiy (Meta-Application Dictionary, aufweist, das Infor- 
mationen Dber eine Komponente (5,, ihre Klassen und die Attnbute in den 
Klassen beinhaltet und die dynamische Konfiguration von Anwendungsin- 
formatbnen und Verarbeitung auf einem Meta-Level erlaubt. 

Abrechnungs- und Kundenverwaitungssystem (1, nach einem der Ansprti- 
*. 1 bis 14, dadurch gekennzeichnet. da R das System („ Einrichtungen 
(68, aulweist. die das Schnittstellenmodel, des Severs auf Cientseite (70) 
zur VerWgung stelten und dami, die eingesetzte Kommunikationstechnologie 
vor einem Client-Entwickler verbergen. 

Abrechnungs- und Kundenverwaltungssystem (1, nach einem der Anspril- 
che 1 b,s 15. dadurch gekennzeichnet. da S das System (,) definierte 
Schnittstellen sowie Mechanismen zur Anfrageverteilung anbietet. so daS 
mehrere gleichartige Anwendungsserver dem System (1, hinzugefug, wer- 

den konnen. 

Abrechnungs- und Kundenverwaltungssystem (1) nach einem der Anspru- 
che 1 bis 16. dadurch gekennzeichnet. da B das System (1) die Moglichkei. 
bietet, Komponenten (5) auszutauschen Oder hinzuzufOgen. 

Abrechnungs- und Kundenverwaltungssystem (1, nach einen, der AnsprQ- 
che 1 bis 17, dadurch gekennzeichnet, daU Klassen erweiterl bzw neue 
Klassen h i„ 2 „ge« g , werden kOnnen. urn eine Komponente wahrend der 
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Ausfiihrung unter Verwendung von Meta-Anwendungs-Einrichtungen zu 
verandern. 

19. Abrechnungs- und Kundenverwaltungssystem (1) nach einem der Ansprii- 
che 1 bis 18, dadurch gekennzeichnet, dad die Datenbank (7) als eine Viel- 
zahl unabhangiger Datenbankabschnitte (12) ausgebildet ist und/oder meh- 
rere unabhangige Datenbanken (12) existieren, wobei die unabhangigen 
Datenbankabschnitte und/oder unabhangigen Datenbanken (12) jeweils mit 
nur einer Komponente (5) kommunizieren. 

20. Abrechnungs- und Kundenverwaltungssystem (1) nach einem der Ansprii- 
ehe 1 bis .19, dadurch gekennzeichnet, daS das System (1) Mechanismen 
zur Verfugung stellt, die ein uber Komponenten (5) verteiltes Transaktions- 
und Speichermanagement ermfiglichen. 
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Zusammenfassung 3 1 M3rz 2000 

Abrechnungs- und Kundenverwaltungssystem 

Die vorliegende Erfindung betrifft ein Abrechnungs- und Kundenverwaltungssystem 
(1), insbesondere fur Kommunikationsdienste, mit mindestens einer Datenbank (7), 
in der Daten gespeichert und abgerufen werden konnen und die bevorzugterweise 
als Server ausgebildet ist. Das System (1) weist eine Mehrzahl von Clients auf, die 
mit der Datenbank (7) kommunizieren, und/oder mindestens einen Anwendungs- 
server mit zugehorigen Clients, der mit der Datenbank (7) kommuniziert, sowie ein 
entsprechendes Framework (10). Dem Benutzer des Systems (1) werden entspre- 
chende Dienstleistungen gernaU den jeweils gewunschten Abrechnungs- und Kun- 
denverwaltungsvorgangen zur Nutzung angeboten. Das System (1) ist dadurch 
gekennzeichnet, daft es eine verteilte Komponentenarchitektur aufweist, in der ent- 
sprechend den angebotenen Dienstleistungen Komponenten (5) ausgebildet sind, 
die uber Schnittstellen direkt miteinander kommunizieren konnen. 



Fig. 2 
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